Fix unwind drop glue for if-then scopes #102394

dingxiangfei2009 · 2022-09-28T09:05:31Z

This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an if-then scope.
MIR validation does not fail for the synchronous versions of the test program, because StorageDead statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where StorageDead must be kept around.

rust-highfive · 2022-09-28T09:05:35Z

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

est31 · 2022-09-28T09:18:57Z

Thanks @dingxiangfei2009 for the fast fix! It's indeed the same issue as @Nilstrieb said.

Beta-nominating as it fixes an ICE in a feature stabilized on beta: #102317

@rustbot label beta-nominated

rustbot · 2022-09-28T09:18:59Z

Error: Label beta-nominated can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

pietroalbini · 2022-09-28T16:43:43Z

@est31 asked for this to be beta-nominated on Zulip.

apiraino · 2022-09-29T14:45:48Z

Beta backport accepted as per compiler team on Zulip

@rustbot label +beta-accepted

compiler/rustc_mir_build/src/build/scope.rs

src/test/ui/let-else/issue-102317.rs

Co-authored-by: SafariMonkey <[email protected]>

SafariMonkey

Thanks for accepting my suggestion! I see you requested re-review from me. This was a drive-by suggestion, and I don't feel qualified to give a general review, so I think someone else should do that.

est31 · 2022-09-30T17:48:11Z

Yeah Rust doesn't really use the github builtin review system. Instead it uses bors. Already now bors has assigned a reviewer to this PR.

est31 · 2022-10-04T18:45:02Z

@dingxiangfei2009 maybe it would be a good idea to r? @oli-obk on this as they have approved your previous PRs, and jackh726 has stated that it's not their area of expertise?

dingxiangfei2009 · 2022-10-05T02:36:09Z

r? @oli-obk

oli-obk · 2022-10-05T07:34:57Z

compiler/rustc_mir_build/src/build/scope.rs

@@ -1021,6 +1023,38 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
        cached_drop
    }

+    /// This is similar to [diverge_cleanup] except its target is set to


Afaict diverge_cleanup could now call this function and pass self.scopes.topmost() as the target_scope argument.

oli-obk · 2022-10-05T07:35:25Z

r=me with some code deduplication

@bors try @rust-timer queue

rust-timer · 2022-10-05T07:35:38Z

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

bors · 2022-10-05T07:36:13Z

⌛ Trying commit 5131e9d with merge 7d853fa063b4f1beb56ab3cb4e2fc8719efee861...

bors · 2022-10-05T16:17:49Z

☀️ Try build successful - checks-actions
Build commit: bf8d3a261764632b6a568ff423d2f29942be0e50 (bf8d3a261764632b6a568ff423d2f29942be0e50)

rust-timer · 2022-10-05T16:26:01Z

Queued bf8d3a261764632b6a568ff423d2f29942be0e50 with parent 8c71b67, future comparison URL.

rust-timer · 2022-10-05T17:47:28Z

Finished benchmarking commit (bf8d3a261764632b6a568ff423d2f29942be0e50): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean¹	range	count²
Regressions ❌ (primary)	1.3%	[1.3%, 1.3%]	1
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.3%	[1.3%, 1.3%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean¹	range	count²
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.7%	[2.2%, 4.6%]	3
Improvements ✅ (primary)	-4.1%	[-4.1%, -4.1%]	1
Improvements ✅ (secondary)	-2.3%	[-4.3%, -1.2%]	4
All ❌✅ (primary)	-4.1%	[-4.1%, -4.1%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

the arithmetic mean of the percent change ↩ ↩²
number of relevant changes ↩ ↩²

oli-obk · 2022-10-05T18:39:29Z

@bors r+

bors · 2022-10-05T18:39:30Z

📌 Commit 565c35a has been approved by oli-obk

It is now in the queue for this repository.

bors · 2022-10-05T20:47:42Z

⌛ Testing commit 565c35a with merge c97d02c...

bors · 2022-10-05T23:41:57Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c97d02c to master...

compiler/rustc_mir_build/src/build/block.rs

rust-timer · 2022-10-06T01:58:54Z

Finished benchmarking commit (c97d02c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean¹	range	count²
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.3%, -2.0%]	2
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

the arithmetic mean of the percent change ↩
number of relevant changes ↩

[beta] backports * Avoid duplicating StorageLive in let-else rust-lang#101894 * Re-add HRTB implied static bug note rust-lang#101924 * Revert "Copy stage0 binaries into stage0-sysroot" rust-lang#101942 * implied_bounds: deal with inference vars rust-lang#102016 * fix ConstProp handling of written_only_inside_own_block_locals rust-lang#102045 * Fix wrongly refactored Lift impl rust-lang#102088 * Fix a typo “pararmeter” in error message rust-lang#102119 * Deny associated type bindings within associated type bindings rust-lang#102338 * Continue migration of CSS themes rust-lang#101934 * Fix search result colors rust-lang#102369 * Fix unwind drop glue for if-then scopes rust-lang#102394 * Revert "Use getentropy when possible on all Apple platforms" rust-lang#102693 * Fix associated type bindings with anon const in GAT position rust-lang#102336 * Revert perf-regression 101620 rust-lang#102064 * `EscapeAscii` is not an `ExactSizeIterator` rust-lang#99880

…-obk Fix unwind drop glue for if-then scopes cc `@est31` Fix rust-lang#102317 Fix rust-lang#99852 This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope. MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.

Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: rust-lang#53667 [RFC 2497]: rust-lang/rfcs#2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes rust-lang#53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: rust-lang#104843 [stay consistent with `if let`]: rust-lang#103293 (comment) [drop order changes]: rust-lang#124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * rust-lang#94927 * rust-lang#94951 * rust-lang#94974 * rust-lang#95008 * rust-lang#97295 * rust-lang#98633 * rust-lang#99731 * rust-lang#102394 * rust-lang#100526 * rust-lang#100538 * rust-lang#102998 * rust-lang#103405 * rust-lang#103293 * rust-lang#107251 * rust-lang#110568 * rust-lang#115677 * rust-lang#117743 * rust-lang#117770 * rust-lang#118191 * rust-lang#119554 * rust-lang#129394 * rust-lang#132828 * rust-lang/reference#1179 * rust-lang/reference#1251 * rust-lang/rustfmt#5910 [original stabilization PR]: rust-lang#94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * rust-lang#115983 * rust-lang#116549 * rust-lang#116688 ### Outside of the compiler * rust-lang/rust-clippy#11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR rust-lang#88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by rust-lang#102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * rust-lang/lang-team#297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: rust-lang/rfcs#3573 [`if_let_guard` tracking issue]: rust-lang#51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [rust-lang#117977](rust-lang#117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [rust-lang#103476](rust-lang#103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in rust-lang#133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by rust-lang#132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): rust-lang#139456 - [x] rust-lang#86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: rust-lang/reference#1740 - [x] Add chapter to the Rust 2024 [edition guide]: rust-lang/edition-guide#337 - [x] Resolve open questions on desired drop order. [original reference PR]: rust-lang/reference#1179 [edition guide]: https://github.com/rust-lang/edition-guide

Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: rust-lang/rust#53667 [RFC 2497]: rust-lang/rfcs#2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes #53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: rust-lang/rust#104843 [stay consistent with `if let`]: rust-lang/rust#103293 (comment) [drop order changes]: rust-lang/rust#124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * rust-lang/rust#94927 * rust-lang/rust#94951 * rust-lang/rust#94974 * rust-lang/rust#95008 * rust-lang/rust#97295 * rust-lang/rust#98633 * rust-lang/rust#99731 * rust-lang/rust#102394 * rust-lang/rust#100526 * rust-lang/rust#100538 * rust-lang/rust#102998 * rust-lang/rust#103405 * rust-lang/rust#103293 * rust-lang/rust#107251 * rust-lang/rust#110568 * rust-lang/rust#115677 * rust-lang/rust#117743 * rust-lang/rust#117770 * rust-lang/rust#118191 * rust-lang/rust#119554 * rust-lang/rust#129394 * rust-lang/rust#132828 * rust-lang/reference#1179 * rust-lang/reference#1251 * rust-lang/rustfmt#5910 [original stabilization PR]: rust-lang/rust#94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * rust-lang/rust#115983 * rust-lang/rust#116549 * rust-lang/rust#116688 ### Outside of the compiler * rust-lang/rust-clippy#11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by #102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * rust-lang/lang-team#297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: rust-lang/rfcs#3573 [`if_let_guard` tracking issue]: rust-lang/rust#51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977](rust-lang/rust#117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476](rust-lang/rust#103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by rust-lang/rust#132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): rust-lang/rust#139456 - [x] rust-lang/rust#86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: rust-lang/reference#1740 - [x] Add chapter to the Rust 2024 [edition guide]: rust-lang/edition-guide#337 - [x] Resolve open questions on desired drop order. [original reference PR]: rust-lang/reference#1179 [edition guide]: https://github.com/rust-lang/edition-guide

rust-highfive assigned jackh726 Sep 28, 2022

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 28, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 28, 2022

fix unwind drop glue for if-then scopes

4a2c1a1

dingxiangfei2009 force-pushed the issue-102317 branch from c1c339b to 4a2c1a1 Compare September 28, 2022 10:45

pietroalbini added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 28, 2022

rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Sep 29, 2022

SafariMonkey reviewed Sep 29, 2022

View reviewed changes

compiler/rustc_mir_build/src/build/scope.rs Outdated Show resolved Hide resolved

tmandry reviewed Sep 29, 2022

View reviewed changes

src/test/ui/let-else/issue-102317.rs Outdated Show resolved Hide resolved

dingxiangfei2009 and others added 2 commits September 30, 2022 21:03

apply suggestion

fb52dc7

Co-authored-by: SafariMonkey <[email protected]>

use build-pass for the test

5131e9d

dingxiangfei2009 requested review from tmandry and SafariMonkey and removed request for tmandry September 30, 2022 13:38

SafariMonkey reviewed Sep 30, 2022

View reviewed changes

rust-highfive assigned oli-obk and unassigned jackh726 Oct 5, 2022

oli-obk reviewed Oct 5, 2022

View reviewed changes

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 5, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Oct 5, 2022

bors removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 5, 2022

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 5, 2022

bors merged commit c97d02c into rust-lang:master Oct 5, 2022

rustbot added this to the 1.66.0 milestone Oct 5, 2022

cuviper mentioned this pull request Oct 6, 2022

[beta] backports #102676

Merged

cuviper reviewed Oct 6, 2022

View reviewed changes

compiler/rustc_mir_build/src/build/block.rs Show resolved Hide resolved

cuviper modified the milestones: 1.66.0, 1.65.0 Oct 6, 2022

cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 6, 2022

dingxiangfei2009 deleted the issue-102317 branch October 6, 2022 09:44

est31 mentioned this pull request Oct 15, 2022

Broken MIR with if let chain #99938

Closed

Nadrieril mentioned this pull request Apr 1, 2024

ice: broken mir with let_chains #122871

Closed

est31 mentioned this pull request Nov 10, 2024

Stabilize let chains in the 2024 edition #132833

Merged

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix unwind drop glue for if-then scopes #102394

Fix unwind drop glue for if-then scopes #102394

dingxiangfei2009 commented Sep 28, 2022 •

edited

Loading

rust-highfive commented Sep 28, 2022

est31 commented Sep 28, 2022

rustbot commented Sep 28, 2022

pietroalbini commented Sep 28, 2022

apiraino commented Sep 29, 2022

SafariMonkey left a comment

est31 commented Sep 30, 2022

est31 commented Oct 4, 2022

dingxiangfei2009 commented Oct 5, 2022

oli-obk Oct 5, 2022

oli-obk commented Oct 5, 2022

rust-timer commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

rust-timer commented Oct 5, 2022

rust-timer commented Oct 5, 2022

oli-obk commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

rust-timer commented Oct 6, 2022

Fix unwind drop glue for if-then scopes #102394

Fix unwind drop glue for if-then scopes #102394

Conversation

dingxiangfei2009 commented Sep 28, 2022 • edited Loading

rust-highfive commented Sep 28, 2022

est31 commented Sep 28, 2022

rustbot commented Sep 28, 2022

pietroalbini commented Sep 28, 2022

apiraino commented Sep 29, 2022

SafariMonkey left a comment

Choose a reason for hiding this comment

est31 commented Sep 30, 2022

est31 commented Oct 4, 2022

dingxiangfei2009 commented Oct 5, 2022

oli-obk Oct 5, 2022

Choose a reason for hiding this comment

oli-obk commented Oct 5, 2022

rust-timer commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

rust-timer commented Oct 5, 2022

rust-timer commented Oct 5, 2022

Overall result: ❌ regressions - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Footnotes

oli-obk commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

bors commented Oct 5, 2022

rust-timer commented Oct 6, 2022

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Footnotes

dingxiangfei2009 commented Sep 28, 2022 •

edited

Loading